Both individual consumers and business entities have long had a need to reconcile, i.e., match, internally generated transactions, i.e., “we” side transactions, against corresponding transactions from a variety of external sources, i.e., “they” side transactions. Also known in the accounting arts are transactions known as “internal” side transactions, though for simplicity's sake discussion herein will focus on “we” and “they” side transactions. However, it should be understood that the present invention is equally application to the processing of “internal” side transactions. An internal transaction is a transaction which involves a single party e.g., a transaction that shifts funds between accounts belonging to a single party. Traditionally, reconciliation has been closely related to accounting methods and principles. A transaction which cannot be reconciled is known as an exception. A simple example is the reconciliation of check register transactions, i.e., “we” side transactions, against corresponding bank statement transactions, i.e., “they” side transactions.
Accounting systems and software exist which aid in reconciliation. However, exceptions still occur even when reconciliation is performed by such systems and software. Whenever a transaction cannot be reconciled using automated techniques, a person must manually reconcile that transaction. This can be an expensive and time consuming process, which may put an account holder in a position of financial risk while an account is unreconciled. Furthermore, for business entities, as different persons may be manually reconciling exceptions, the exceptions may not be resolved on a consistent, best practice basis.
Large business entities generate an ever-increasing volume and complexity of transactions which require reconciliation. In addition to a massive amount of transactions to reconcile, often reconciliation is not a one-to-one process. That is, a “they” side transaction may encompass multiple “we” side transactions, or vice-versa. This volume and complexity often results in a delay in reconciling transactions, which in turn results in a delay in providing critical information to the business entity.
Furthermore, problems associated with reconciliation are exacerbated when a business entity deals in different types of transactions, i.e., cash transactions, securities transactions, and foreign exchange/trade transactions. Transactions of the same type are said to belong to the same balance pool. Typically, business entities are structured such that different departments and personnel are responsible for only one type of balance pool. However, related transactions are often found in different balance pools, such related transactions are known as cross-domain transactions. Cross-domain transactions often give rise to exceptions. When an exception exists involving a cross-domain transaction it is often a difficult and time-consuming manual endeavor to resolve the exception, especially since information necessary to resolve the exception exists in association with a transaction belonging to a balance pool different than the balance pool for which the person reconciling the exception has responsibility.
Accordingly, a need exists for a technique to facilitate manual reconciliation of cross-domain transactions.
Existing accounting systems and software packages are designed to reconcile transactions of one type, i.e., transactions belonging to the same balance pool, not cross-domain transactions. As a result, a cross-domain transaction will often result in an exception which requires manual reconciliation because information necessary for reconciliation is unavailable to the system or software.
Accordingly, a need exists for an automated technique to electronically reconcile cross-domain transactions.